Modern electronic computing systems, such as microprocessor systems, are often organized as networks of discrete devices, which require interconnection and intercommunication. Networking demands are increasing rapidly, somewhat independent of hardware advances, and therefore frequently exceed the capacity of many network devices. For example, bandwidth-intensive applications such as online content, e-commerce, large databases, and streaming media require significantly more network bandwidth than conventional textual data. In fact, some of the most widely-used one-Gigabit Ethernet network adapters do not meet the network bandwidth demand in some bandwidth-intensive environments.
The industry developed the EtherChannel and IEEE 803.3ad technologies to address these bandwidth-intensive business needs. FIG. 1 illustrates a typical configuration, shown as system 100. Generally, EtherChannel/803.3ad groups multiple Ethernet network adapters together to form a single larger pipe, as shown in FIG. 1. For instance, four 1-Gbit Ethernet adapters can be combined in a server to form a single 4-Gbit network interface using one IP address.
More specifically, application (or application layer) 102 transmits an addressed packet to TCP/IP layer interface 104, of socket 106. TCP/IP interface 104 passes the addressed packet to EtherChannel driver 110, which selects one of the several available Ethernet “ports,” and passes the addressed packet to the selected port's Ethernet driver 120. The Ethernet driver 120 processes and forwards the received packet to its associated Ethernet adapter 122. System 100 includes four conventional Ethernet drivers 120 and four associated conventional Ethernet adapters 122. Generally, EtherChannel driver 110 groups the four ports together to form a single pipe, with the bandwidth of all four ports combined.
The EtherChannel model typically comprises mostly software load balancing functionality, illustrated in FIG. 1 as EtherChannel driver 110, and runs from a processor on the Ethernet server. Specifically, in one configuration, the EtherChannel “port aggregation” software evenly allocates the data packets among available adapters in a round-robin fashion. In another configuration, the EtherChannel software allocates the data packets based on a hash function of part of the packets' addresses. The EtherChannel model provides adequate performance, but suffers from some significant limitations.
First, EtherChannel requires additional software not necessary in standard Ethernet configurations. This additional software adds some latency. Second, the EtherChannel software is typically configured under an N-to-1 receive and 1-to-N transmit model, where “N” is the number of ports. In multiple-CPU environments, software locking can be a scaling issue when the number of ports in the EtherChannel increases.
Third, EtherChannel systems experience a longer delay for error indications to arrive from the Ethernet adapter hardware. That is, the EtherChannel driver 110 will occasionally transmit data to a particular port, while that port is down or otherwise malfunctioning. The EtherChannel driver 110 must wait for the data packet to “bounce” before reallocating the data stream among the remaining ports. The delay in error detection and notification can cause more data to be dropped.
Fourth, the typical “Kernel Interrupt” function is ordinarily a single-threaded function. As such, the interrupt generated by the last port or a down port experiences longer latency for servicing, which causes additional bandwidth reduction. Fifth, under standard EtherChannel configurations, interrupt servicing typically requires context switching for each interrupt between the ports. This context switching adds CPU cycles, and therefore latencies, which also reduce available effective bandwidth.
Therefore, there is a need for a system and/or method for Ethernet load balancing that addresses at least some of the problems and disadvantages associated with conventional systems and methods.